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Management of a communication network and the migragtion of mobile agents 



(57) . A technique for managing the migration of mo- 
bile agents to nodes of a communication network is pro- 
posed. The trustworthiness of at least one node (102b) 
of the network is checked (301 ). In case the trustworthi- 
ness exceeds a pre-set trust threshold, a trust token for 
the checked node (102b) is generated (306) and the 



trust token is stored (303) in the network. In advance to 
a migration of a mobile agent (104a) to a node of the 
network it is verified (108, 109) if a valid trust token is 
existing for the corresponding node (102b). The migra- 
tion of the mobile agent (104a) is restricted (107) to 
nodes having a valid trust token. 
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Description 

[0001] The present invention relates to a communica- 
tion network, a method for managing a communication 
network and method for managing the migration of mo- 
bile agents to nodes of a communication network. 
[0002] The present invention has its application in the 
field of communication networks, and preferably in the 
field of mobile computing, wireless communication, mo- 
bile multimedia middleware and so-called mobile 
agents. One particular application is the control (man- 
agement) of the migration of so-called mobile agents be- 
tween places in the network. 

[0003] Communication is concerned with providing 
networked services over (for example wireless) net- 
works to the users. So-called mobile agents is a new 
computing concept enabling the transfer of an executing 
piece of software (code) from one node of the computer 
network to another node. One example for a mobile 
code system are Java applets loaded over the Internet 
in a Web browser system. 

[0004] The concept of mobile agents is set forth in de- 
tail in US-A-5 603 031 . Regarding the general concept 
of the mobile agent technology therefore reference is 
made to said prior art. 

[0005] Figure 1 shows the basic operation of a mobile 
agent system. An agent system offers mobile agents an 
execution environment which is called a place. Mobile 
agents are a piece of executing software being capable 
of migrating from one agent system to another. On all 
places mobile agents can access local services offered. 
[0006] Figure 1 shows the migration of a mobile agent 
104a between two agent systems 101a, 101b. The 
agent systems contain execution environments which 
are called places 102a, 102b. In the places local serv- 
ices 103a, 103b are provided offering services 106 to 
the mobile agent 104a. In the migration process 105 the 
mobile agent is serialised on place 102a and the state 
and the code of the agent is transferred to the place 
102b. In the place 102b the mobile agent 104a is recre- 
ated from the transferred state and code. Then the ex- 
ecution thread of the mobile agent 104a can be execut- 
ed in the place 1 02b. 

[0007] In the current state of the art agents are migrat- 
ing between computing nodes on the Internet. There are 
several security-related problems in conjunction with 
mobile agents, e.g. to protect the agent place against a 
malicious agent. One hard problem is the protection of 
an agent against a malicious host. 
[0008] A malicious host can perform several kinds of 
attacks to a mobile agent like e.g. spy out its code or 
data, manipulate its code or data, execute it incorrectly 
or deny the execution at all. At the moment there are no 
known security mechanisms, which protect an agent 
against all these attacks except of using trusted hard- 
ware. 

[0009] A malicious host is only a problem for agents 
whose owners cannot trust the place operators. Trust 
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means in this context that the owner of the agent knows 
(or at least hopes) that the place will not attack one of 
its agents. As there is no solution for protecting agents 
against malicious places, there are some approaches 
to circumvent this problem by allowing agents only to 
move to hosts trusted by the owner of the mobile agent. 
[0010] These approaches are especially important 
when the itinerary of an agent is not known in advance. 
In most agent environments an agent can retrieve dur- 
ing runtime the location of certain services and then visit 
these locations. In this case the agents itinerary is de- 
termined dynamically. This is in contrast to a static ap- 
proach to inform a mobile agent in advance concerning 
which places are not rusted by the owner of the mobile 
agent. It is to be noted that even the trustworthiness 
places can change in time, i.e. a trustworthy place can 
become non-trustworthy later on which results in prob- 
lems when informing a mobile agent in advance about 
the trustworthiness of places to be vissited. 
[0011] A mobile agent owner might want to restrict the 
agent in a way that it is not allowed to migrate to places 
the mobile agent owner does not trust. To achieve this, 
the agent needs a means to find out if a given place is 
trusted by his user or not. 

[0012] This can be done either by an „ organisational" 
approach, which means that only trustworthy parties 
can start a place. The disadvantage of this approach is 
that it leads to an agent environment, which is not ,, 
open" anymore (open in the sense that everybody can 
start a place). 

[001 3] Another approach is to specify the trusted plac- 
es an agent is allowed to migrate in advance. In this 
case, the agent carries a list of trusted places and either 
the agent system or the agent itself checks on a migra- 
tion whether the agent is allowed to go to its destination 
or not. 

[0014] This approach also has a big disadvantage: it 
is not always clear in advance whether a place is trusted 
or not, which can severely reduce the number of places 
an agent is allowed to migrate. A user normally 'knows' 
only a small number of places in the agent environment. 
He can of course only judge agent systems he knows. 
Therefore he will probably not trust most of the places 
which means that his agents are only allowed to migrate 
to a very limited set of places. This may limit the useful- 
ness of an agent environment significantly. 
[0015] In view of the above prior art it is the object of 
the present invention to provide for a technique allowing 
for a facilitated trust check in networks. It is particularly 
the object of the invention to provide such a trust check 
for the management of the migration of mobile agents 
in a communication network. 

[0016] The trust check technique should furthermore 
be open for a dynamic in-line trust check approach. 
[0017] The above object is achieved by means of the 
features of the independent claims. The dependent 
claims develop further the central idea of the invention. 
[0018] According to the present invention therefore a 



2 



3NSDOCID: <EP 1067457A1_I_> 



3 



EP 1 067 457 A1 



4 



method for managing a communication network is pro- 
vided. The trustworthiness of at least one node of the 
network is checked. The trustworthiness is compared to 
a pre-set threshold and in case the trustworthiness ex- 
ceeds the pre-set trust threshold, a trust token for the 
checked node is generated and the trust token indicat- 
ing the fact that the corresponding node has passed the 
trustworthiness check is stored in the network. 
[001 9] The validity of a token can be ensured by cryp- 
tographic measures such as I.e. difital signatures. 
[0020] The step of checking the trustworthiness of at 
least one node of the network can be executed by an- 
other node of the network having a trust centre function 
which is called trust centre in the following description. 
[0021] A predetermined expiry date limiting the life 
span of a trust token can be added to the trust token. 
[0022] According to another aspect of the invention a 
method for managing the migration of mobile agents to 
nodes of a communication network is provided. The 
trustworthiness of at least one node of the network is 
checked. In case the trustworthiness exceeds a pre-set 
trust threshold, a trust token for the checked node is 
generated and stored in the network. In advance to mi- 
gration of mobile agent to a node of the network, it is 
verified if a valid trust token is existing for the corre- 
sponding node. The migration of the mobile agent is re- 
stricted to nodes having a valid trust token. 
[0023] The verification of the trust token can be exe- 
cuted dynamically during the run time of a mobile agent. 
[0024] The step of checking the trustworthiness of at 
least one node of the network can be executed by at 
least one third node of the network having a trust centre 
function. 

[0025] A list of names of trust centre nodes can be 
attached to a mobile agent. The list can be protected 
against attempts of manipulation by cryptographic 
measures such as f.e. digital signatures. 
[0026] The step of verification if a valid trust token is 
existing for a corresponding node in advance to a mi- 
gration of the mobile agent can be effected by querying 
the corresponding target node for valid trust token. Ad- 
ditionally or alternatively at least one trust centre node 
can be queried and/or at least one storage unit storing 
valid trust token and the corresponding nodes of the net- 
work can be queried. 

[0027] According to the present invention furthermore 
a communication network is provided. At least one trust 
centre node of a network checks the trustworthiness of 
at least one node of the network. The trust centre node 
has a token creator for generating a trust token for the 
checked node in case the trustworthiness exceeds a 
pre-set trust threshold. The trust centre can be another 
node of the network as each checked node. The trust 
token and the corresponding checked nodes can be 
stored in a trust manager database being part of or being 
connected to the trust centre node. 
[0028] At least one mobile agent place can be provid- 
ed in the network for managing the migration of mobile 



agents in the communication network. The mobile agent 
places can be signed to access the trust manager da- 
tabase of at least one trust centre node. 
[0029] The mobile agent place can comprise a local 

5 database to store information fetched from the trust 
manager database of a trust centre node. 
[0030] A list of trust centre nodes can be attached to 
a mobile agent managed by a mobile agent place. 
[0031] In the following preferred embodiments of the 

io present invention will be explained with reference to the 
figures of the enclosed drawings. 

Figure 1 shows the migration of a mobile agent, 
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Figure 2 shows a wireless computing scenario, 

Figure 3 shows the relationship between a trust 
centre node, an agent place and a directory service, 

Figure 4 shows the system architecture for a trust 
centre, 

Figure 5 shows a trust token with some related data 
fields, and 

Figure 6 explains the architecture of a agent sys- 
tem. 



[0032] Figure 1 has already been explained in the in- 

30 troductory part of the descritpion. 

[0033] Figure 2 shows a typical wireless computing 
scenario. Several mobile devices are connected over a 
wireless network link to a base station. They use differ- 
ent wireless network equipment. The base stations are 

35 connected over a network (e.g. the Internet) with each 
other and with network servers. 

[0034] Figure 3 shows the relationship between the 
trust centre a agent place and a directory service. The 
trust centre generates a trust token and issues it to the 

40 agent place. This place can then declare its trustworthi- 
ness using the issued trust token. Agent wishing to mi- 
grate can request the trust tokens from several places 
(the target agent place, the trust centre, a directory or 
others). The checks can be performed by the agent or 

45 by the agent system. 

[0035] A place may get trust tokens from various trust 
centres. Trust token may also be made public by the 
trust centres or the place, so everybody can verify that 
a place is trusted by a specific trust centre ('Publishing 

so of the trust centre"). This can be done through the use 
of a directory service like the international X.500 direc- 
tory. Figure 3 explains this process. 
[0036] Figure 4 shows the system architecture for a 
trust centre. The trust centre contains a token creator 

55 module, which creates a trust token after the credibility 
of a agent place is checked. It used cryptographic and 
digital signatures for ensuring the validity of his state- 
ment. The trust token is managed by the trust manager 
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module which stores the trust token and addition infor- 
mation in a trust token database. The revoke manager 
module is a supplementary module which enables to de- 
fine tokens as revoked after they are issued. Although 
this is not a 100% solution it increases the likelihood of 
preventing accidental migration to untrusted places. 
The revoke list can be distributed to interested agent 
places to improve the checking of the trust tokens. The 
token requester module handles request for issued trust 
tokens from agent places. The directory access module 
allows access to a directory service. 
[0037] There is a plurality of implementation possibil- 
ities for the revoking procedure: 

- a mobile agent is provided with a revoke list 

- the trust centre is accessed to query revoked plac- 
es, and/or 

- a central revoke manager is provided 

[0038] As shown in figure 4 a trust centre consists of 
several modules, each performing a specific task. The 
token creator module creates the trust token. The trust 
token consists of some information about the trusted 
agent place. This information is digital signed with the 
private key of the trust centre so that user of the trust 
token can verify that the content of it was created by the 
trust centre. 

[0039] On the side of the agent place, trust tokens are 
managed by the trust token manager. This module can 
keep a cache of already available trust tokens. The re- 
voke list manager module stores a list of revoked trust 
tokens. It can synchronise its content with the revoke 
list database from the trust centre. 
10040] The information, if a place is trustworthy or not, 
is determined dynamically during the runtime of the 
agent. This is achieved by providing adding trusted third 
parties - called trust centres. An owner of an agent can- 
not only specify places he trusts but also trust centres. 
The list an agent carries around will therefore consist of 
place names and trust centre names. This list is called „ 
System Permission List" (SPL). Figure 5 explains the 
System Permission List as an example implementation 
of a trust token. The data fields have the following mean- 
ing: 



serialNumber 



owner 



centre. 

- A serial number for the trust to- 
ken. 

- The owner of the agent place. 



trustLevel 

agentPlace 
startDate 

expiryDate 

issuingAuthority 



- The level of trust given by the 
trust centre to the referenced 
agent place. 

- The name of the agent place. 

- The start date from which on the 
trust token is valid. 

- The date when the trust token 
expires. 

- The name of the issuing trust 



[0041] Depending on the application requirements, 
the trust token might have additional data fields. 
[0042] Figure 6 explains the architecture of a -Agent 
System" in conjunction with the trust mechanism. When 
a agent wants to migrate to another agent place. It calls 
the migratbn operation (usually called -Go"). Execution 
control is then transferred to the migration manager. 
This module in turn calls the trust manager to ensure 
that the agent is allowed to migrate. The trust manager 
checks locally with the trust token manager whether a 
required trust token is already stored. It further checks 
with the revoke list manager to ensure the status of the 
trust token. If it cannot find a required token locally, it 
uses the trust token requester to get a trust token from 
the agent place, a directory service, or the trust centre. 
If the new trust token passes the revoke list manager 
test ; the agent is handed to the migration handler mod- 
ule which performs the migration procedure. 
[0043] A place can get a kind of license (a trust token) 
from a trust centre, if the trust centre is convinced that 
the place is trustworthy. To determine, if a place is trust- 
worthy the trust centre can e.g. check the owner of the 
place, the software etc. One can even think of checking 
the everyday operation of the organisation operating the 
agent place. Every trust centre may have different re- 
quirements a place has to fulfil before it gets a license 
from it. Even a single trust centre may have different lev- 
els of such requirements resulting in different levels of 
licenses. 

[0044] If a place fulfils the requirements of a trust cen- 
tre it gets the license (..Issuing of the trust token"). This 
kind of license is called a trust token. A trust token is a 
statement digitally signed by the issuing trust centre, 
containing the information that a specified place is trust- 
ed by the issuer and also some additional information. 
Trust tokens are very similar to certificates used in au- 
thentication protocols. A trust centre is very similar to a 
certificate authority in the same context. 
[0045] Trust centres may charge places for their serv- 
ices 

Figure 6 explains the architecture of a sending agent 
system. An agent wishing to migrate to another agent 
place issues this request to the migration manager. The 
migration manager inquires a trust manager about the 
trustworthiness of the other agent place. The trust token 
requester retrieves the trust token using one of the pos- 
sible ways (e.g. accessing the peer agent place, access- 
55 ing the directory or accessing the issuing trust centre). 
[0046] If the 4rust token allows the migration the mo- 
bile agent will be handed to the migration handler which 
executes the migration step. 
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[0047] If an agent now wants to migrate to a place and 
the place is not contained in the list of trusted places. It 
tries to check whether the place has a trust token from 
a trust centre the agent trusts. This can be done in sev- 
eral ways. 

1 . The agent may get one of the wanted trust tokens 
by asking the destination place. 

2. He can ask the trust centres 

3. He can ask other services which stores and man- 
ages trust tokens (e.g. a directory service). 

[0048] If the agent can get a trust token issued by a 
trust centre, which is in his SPL he is allowed to migrate. 
Otherwise the agent is not allowed to migrate. The 
whole test can be done by the agent himself or by the 
agent place. 

[0049] If the agent is allowed to migrate then there is 
something like a trust chain: the user trusts a trust cen- 
tre, which in turn trusts the destination place. 
[0050] One problem of a trust token concept is that 
sometimes an issued trust token has to be revoked. This 
is a hard problem as trust tokens are distributed without 
control of the trust centre. By adding an expiry date, trust 
tokens have a limited lifetime so that the trust centre can 
be sure that a trust token is not valid anymore. Further- 
more, the trust centre can maintain a revoke list which 
contains all tokens revoked before their expiry date. 
[0051] The system required for this invention consists 
of the trust centre, the trust token data structure and the 
integration of a trust manager into the agent system. 
[0052] A created trust token is stored in the token 
manager database. This database manages all issued 
trust tokens together with additional information when 
the cite was checked, which tests have been performed, 
etc. The trust token is then communicated to the agent 
place which can add the trust token to its database of 
locally managed trust tokens. This database is man- 
aged by the trust token manager component of an agent 
place. 

[0053] If a trust token has to be revoked early, the re- 
voked trust token are stored in a database managed by 
the revoke manager Note that because of the distribut- 
ed nature of the system, trust token remain valid until 
their expire date is over. The revoke operation is just an 
additional mean for agent places to verify that a given 
trust token is still valid. As this comparison with the trust 
centre revoke list is not mandatory, the trust token can- 
not reliably be revoked early. 

[0054] The trust centre can furthermore use the direc- 
tory access module to store the trust token in a generally 
accessible directory service. Using the token requester, 
anybody can request an issued trust token for a specific 
agent place. 

[0055] In an agent place, the collection of trust tokens 
is stored locally in a database managed by the trust to- 



ken manager. If trust tokens are requested from another 
place, the trust token is fetched from the database and 
transmitted to the requester. An instance requesting a 
trust token can therefore use either the agent place, the 
5 directory or the trust centre itself for requesting the trust 
token. Other means are also possible. 

Example 

10 [0056] Agent a wants to migrate from place pi to 
place p2. His SPL does not contain p2, but the trust cen- 
tres tc1 and tc2. Now it must be checked if p2 owns a 
trusl token from either tc1 or tc2. To achieve this p2 is 
asked to provide all trust tokens it owns. P2 owns trust 

is tokens from the trust centres tc3, tc2 and tc4. It sends 
theses tokens to pi . P1 now checks whether one of the 
trust tokens from p2 matches a trust centre in the SPL 
of a. This is the case as p2 owns a trust token from tc2 
and tc2 is in the SPL of a. The agent is therefore allowed 

20 to migrate. 

Main advantageous differences between the 
invention and the state of the art 

2S [0057] By introducing a third party we gain the advan- 
tage that the user must not know all places his agents 
may travel by himself without allowing the agents to visit 
untrusted places. Our approach therefore does not re- 
strict the number of places as much as the original ap- 

30 proach did. 

[0058] As trust centres may be able to perform a lot 
of checks to a place or can make a contract with the 
place owner, the trust relationship between the trust 
centre and the place is in most cases much more justi- 

35 fied than the trust relationship between an agent owner 
and the place. 

[0059] The original approach had the problem that the 
SPL could become very large as the user specified sin- 
gle places. As this list has to be moved together with the 

40 agent this is not a very good thing - especially if the agent 
migrates over a wireless network link with limited band- 
width. According to the present approach the SPL is 
much shorter, as the user can specify with one entry im- 
plicitly a whole set of agent systems. 

45 [0060] One example of an application of the present 
invention is a bank offering services on the base of mo- 
bile agents. Several places for mobile agents are of- 
fered. The bank is its own trust centre for these places 
and issues trust token for said places. A mobile agent 

so which wants to use the services offered by the bank in- 
cludes the trust token of the bank in its SPL. 
[0061] The invention as shown above presents 
means and methods for managing trusted places in a 
mobile agent system. The apparatus restricts the migra- 

55 tion operation ol the mobile agents to the boundaries 
defined by the trusted places. The invention contains 
means and methods for controlling the trustworthiness 
of an agent place. The migration operation of a mobile 
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agent is restricted by a system using trusted system 
concepts. The system has accessed to a list of trusted 
systems defined by the user or trust labelling authorities. 
It can check whether a migration is allowed on the basis 
if the target node of the network is trusted or not. 
[0062] The invention focuses on the way how the 
trustworthiness of a place is determined. In addition to 
the usual list of places which are allowed to be visited, 
a user can define a list of trust checking agencies (trust 
centres). These trust centres are certificating agent 
places for the trustworthiness. If a place is considered 
trustworthy, the trust checking agency is issuing a trust 
certificate which is stored at the agent place. Trust cer- 
tificates are encoded to prevent the manipulation. Be- 
fore migrating to an agent place : the mobile agent can 
request the trust certificates of that place and check 
them against its own list of trust checking agencies. If a 
trust certificate fits, the agent is allowed to migrate. 



Claims 



1. Method for managing a communication network, 
comprising the following steps: 

checking (301) the trustworthiness of at least 
one node (102a) of the network, 
comparing the trustworthiness of the checked 
node (102a) of the network with a preset trust 
threshold, 

in case the trustworthiness exceeds a preset 
trust threshold, generating (306) a trust token 
for the checked node (102a) and storing (303) 
the trust token in the network, wherein the trust 
token indicates that the corresponding node 
(102a) has passed the trustworthiness check. 

2. Method according to claim 1 , 
characterized in that 

the step of checking (301) the trustworthiness of at 
least one node (102a) of the network is executed 
(306) by another node (301 ) of the network having 
a trust center function. 

3. Method according to anyone of claims 1 or 2, 
characterized by 

the step of adding a predetermined expiry date to a 
trust token. 

4. Method for managing the migration of mobile 
agents to nodes of a communication network, 
comprising the following steps: 

checking (301) the trustworthiness of at least 
one node (102b) of the network, 
in case the trustworthiness exceeds a preset 
trust threshold, generating (306) a trust token 
for the checked node (102b) and storing (303) 



the trust token in the network, wherein the trust 
token indicates that the corresponding node 
(102a) has passed the trustworthiness check, 
in advance to a migration of a mobile agent 
s (104a) to a node of the network, verifying (108, 

109) if a valid trust token is existing for the cor- 
responding node, and 

restricting (107) the migration of the mobile 
agent (104a) to nodes having a valid trust to- 
to ken. 

5. Method according to claim 4, 
characterized in that 

the verification (1 08, 1 09) if a valid trust token is ex- 
is isting for the corresponding node is executed dy- 
namically during the runtime of a mobile agent 
(104a). 

6. Method according to claim 4 or 5, 
characterized in that 

the step of checking (301) the trustworthiness of at 
least one node of the network is executed by at least 
one third node (301) of the network having a trust 
center function. 

Method according to claim 6, 
characterized in that 

a list of trust center nodes is attached to a mobile 
agent (104a). 

Method according to anyone of the preceding 
claims, 

characterized in that 

the step of verification (108, 109) if a valid trust to- 
ken is existing for the corresponding node in ad- 
vance to a migration of the mobile agent (104a) is 
effected by 

querying (111) the corresponding target node 
(102b) for valid trust token, 
querying (112) at least one trust center node 
(301), and/or 

querying (113) at least one storage unit storing 
valid trust token and the corresponding nodes 
45 of the network. 

9. Method according to anyone of the preceding 

claims, 

characterized by 
so the step of adding a predetermined expiry date to a 
trust token. 
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10. Software element for executing, when loaded in a 
computing device, a method according to anyone 

55 of the preceding claims. 

11. Communication network, 

comprising at least one trust center node (301) for 
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checking the trustworthiness of at least one node of 
the network, and in case the trustworthiness ex- 
ceeds a preset trust threshold, the trust center node 
(301 ) having a token creator (306) for generating a 
trust token for the checked node, the trust center 
node being another node of the network as each 
checked node (102b), 

wherein the trust token and the corresponding 
checked nodes are stored in a trust manager data- 
base (303) being part of or being connected to the 
trust center node (301). 

12. Communication network according to claim 11 
characterized by 

at least one mobile agent place (101a) manag- 
ing the migration of mobile agents in the com- 
munication network, 

the mobile agent places ( 1 01 a) being designed 
to access the trust manager database (303) of 
at least one trust center node (301). 

13. Communication network according to claim 12, 
characterized in that 

the mobile agent place (101a) comprises a local da- 
tabase to store information fetched from the trust 
manager database (303) of a trust center node 
(301). 

14. Communication network according to anyone of 
claims 11 to 13, 

characterized in that 

a list of trust center nodes attached to a mobile 
agent (104a) managed by a mobile agent place 
(101a). 

15. Communication network according to anyone of 
claims 11 to 14, 

characterized in that 

each trust token comprises an expiry date. 
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